Field
The described embodiments relate to processing interrupts. More specifically, the described embodiments relate to processing interrupts using heterogeneous processor types in a computing device.
Related Art
Many modern computing devices include processors (central processing units (CPUs), graphics processing units (GPUs), etc.) that provide support for handling interrupts. Generally, interrupts are signals that are emitted by hardware or software entities that indicate to processors that corresponding events are to be processed by the processors. For example, a peripheral device that encounters as an input-output (I/O) event that is to be processed by a processor can signal a corresponding interrupt by emitting a signal to the processor indicating that the I/O event has occurred. Upon receiving the interrupt signal, the processor typically pauses processing operations for other program code and immediately processes the I/O event. Because processing interrupts disrupts the operation of processors (e.g., disrupts the processing of the other program code), efficient processing of interrupts is important in computing devices.
In an attempt to improve the operation of computing devices, designers have proposed a number of techniques for processing interrupts as alternatives to simply processing interrupts in receiving processors as described above. For example, in some computing devices with multiple processors, a software interrupt stack in a receiving processor may forward interrupts to another processor based on load levels of the processors. In such computing devices, however, significant overhead and delay is added to the processing of interrupts due to the handling of interrupts by software, and the software stack must be provided for the computing devices.
As another example, in some computing devices with multiple processors, I/O interrupt controllers (which route interrupts received from peripherals) determine a processor to which interrupts are routed based on a straightforward load-balancing algorithm (e.g., round-robin) and/or the load and priority of tasks on each processor. In these computing devices, however, the I/O interrupt controller may route interrupts to processors that can process the interrupt, but that are less than optimal for processing such interrupts (i.e., are optimized for other types of processing, are more remote from memory to be accessed in processing the interrupt, etc.).
As yet another example, in some computing devices with multiple processors, an interrupt controller can be configured to route particular interrupts to specific individual processors. This technique, however, is limited to manually directing each particular interrupt to a specific individual processor.
As yet another example, some computing devices with multiple processors also include a purpose-specific auxiliary processor that is specifically designed for processing interrupts. Although offloading processing of interrupts from other processors to the auxiliary processor in such computing devices, these computing devices lack the ability to optimally route interrupts to any of the available processors based on interrupt types and/or processor types, and require the additional auxiliary processor.
As yet another example, in some computing devices with multiple processors, an embedded/specialized processor includes custom logic for handling some types of interrupts. In these computing devices, such features are hard-coded in the embedded/specialized processor, and do not provide flexibility in mapping/remapping of different types of interrupts to different processors and require the addition of the embedded/specialized processor.
As yet another example, some computing devices with multiple processors can remap individual interrupts received from peripheral devices to particular processors. In existing computing devices, however, such remapping is relatively static and limited in scope in terms of interrupts that may be remapped and/or processors to which the interrupts may be remapped, and must be synchronized with mutually asynchronous activities on the peripherals and the processors.
As yet another example, some computing devices with multiple processors include a hardware interrupt queuing mechanism from which enqueued interrupts may be redirected to processors by corresponding software. This technique, however, requires that interrupts be enqueued (i.e., requires the addition of queuing mechanism) and requires software intervention and processing for redirecting the enqueued interrupts.
The above-described techniques can improve certain aspects of processing interrupts in computing devices, but the techniques are associated with interrupt processing overhead, design complexity, inflexibility, significant additional hardware, and/or other negative aspects. Improving the overall efficiency of operation of computing devices while processing interrupts without unduly increasing the complexity or cost of the computing devices remains a challenge.
Throughout the figures and the description, like reference numerals refer to the same figure elements.